% !TEX root = main.tex

\subsection{MDS Methodologies using Tailored DSLs}
\label{sec:tailoreddsl}

\begin{figure}[t]
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\textwidth]{./figures/ProSecO}
\caption{Synthesis of ProSecO}
\label{fig:ProSecO}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\textwidth]{./figures/ModelSec}
\caption{Synthesis of ModelSec}
\label{fig:ModelSec}
\end{minipage}
\end{figure}
	

%\begin{figure}[t]
%	\centering
%	\includegraphics[width=0.6\textwidth]{./figures/ProSecO}
%	\caption{Synthesis of ProSecO}
%	\label{fig:ProSecO}
%\end{figure}
%
%\begin{figure}[t]
%	\centering
%	\includegraphics[width=0.6\textwidth]{./figures/ModelSec}
%	\caption{Synthesis of ModelSec}
%	\label{fig:ModelSec}
%\end{figure}

To overcome the limitations inherent to \UML profiling (\emph{c.f.} \sect \ref{sec:criticism}), newer \mds methodologies like \textsl{ProSecO} and \textsl{ModelSec} proposed to model business and security using tailored \DSL{}s. 
They both define a generic security requirement metamodel to be able to cover multiple security concerns. \textsl{ModelSec} even proposes a generic security architecture for \mds: 
their \DSL can easily be extended with new security concerns, and model-to-model transformations (M2M) allow to generate ``skeletons'' of model dependencies.

% ProSecO
\smallskip\noindent \textbf{ProSecO}\\
\indent \textsc{Security Concerns.} 
Besides access control analysis in \emph{SECTET}, Breu \etal then recognized the fact that 
``for a thorough security analysis not only the information objects but also the applications, business processes and the organization supporting the creation and processing of information have to be considered''.
So in \cite{10.1007/978-3-540-78942-0-8}, they proposed another overall security modeling and analysis framework, called \emph{ProSecO}. 
The objective of the new framework \emph{ProSecO} is to handle
\emph{modularity}, \emph{traceability} and \emph{model-driven configuration of security services} in a \emph{heterogeneous} environment due to stakeholders' various organizational structures,
security regulations and infrastructures.

\textsc{Modeling \& Analysis.} 
\emph{ProSecO} defines Global/Local system metamodel for functional modeling, in which elements are classified along two orthogonal categories, \ie level of interaction and level of abstraction.
Besides it also defines another security metamodel which tries to cover general security objectives and detailed context-dependent security requirements.
After modeling modular components, system behaviors are modeled by identifying \emph{Dependency Graph} among those components and security concerns can be integrated in the dependency graph by annotating
on the specific components.
In \emph{ProSecO}, users can only perform \emph{qualitative} security analysis on the \emph{Annotated Dependency Graph} by evaluating threats and risks and finally produce a risk evaluation report manually.
The modeling is supported by the toolset developed in \emph{SECTET}, but no tool support for security analysis and code-generation in \emph{ProSecO}.

\textsc{Transformations.}
\emph{ProSecO} doesn't provide enforcement infrastructure generation at the moment.

\textsc{Traceability.}
\emph{ProSecO} doesn't provide formal traceability support. The backtracking is based on qualitative analysis of the risks and the dependencies among the system components.

The synthesis of \emph{ProSecO} according to the Y-Model is shown in \fig \ref{fig:ProSecO}.

% ModelSec
\smallskip\noindent \textbf{ModelSec}\\
\indent \textsc{Security Concerns.} 
S\'anchez \etal proposed \textsl{ModelSec} \cite{sanchez:jucs-15-15} as a generative architecture for \mds, following \mda pattern.
\textsl{ModelSec} supports the definition of requirements as a catalog from which models can be derived. 
It is designed to model and analyze multiple security concerns in one security model, 
including \emph{privacy, integrity, access control, authentication, availability, non-repudiation} and \emph{auditing}.

\textsc{Modeling \& Analysis.}
\emph{ModelSec} first proposed a core \emph{requirements metamodel} as a reference model for requirements meta-modeling. Then functional requirement model and security requirement model
can be extended from the general requirements metamodel by integrating business concepts and security concepts respectively.
Due to generality, the authors proposed an extended security requirement model by integrating seven categories of security concerns, \eg privacy, integrity, access control, \etc.

Different from profiling UML, \emph{ModelSec} provides a tailored \dsl for modeling security concerns, called \emph{SecML} (Security Modeling Language).
Since both functional requirement model and security requirement model are inherited from general requirement metamodel, the \emph{SecML} can be also used to specify system functions.

%The authors did not explain clearly how to integrate security model with functional model except some mappings from security decisions to data resources in the security design model later after,
%which is a weak conformance to the model integration feature in the Y-Model.

The security analysis is performed informally on security design model, which is a drawback of \emph{ModelSec}.

\textsc{Transformations.}
The security requirement model (the same to the functional requirement model) can be transformed to security design model by mapping each requirement
to an instance of a certain meta-class in the security design model with decision attributes, including platform specific information (conforming perfectly to the \mda paradigm).

However, in the final model-to-code transformation, only \textsc{Xacml} policies and Oracle PL/SQL script are auto-generated that lacks of system infrastructure.

\textsc{Traceability.}
Traceability is not available at the moment in \emph{ModelSec}.

The synthesis of \emph{ModelSec} according to the Y-Model is shown in \fig \ref{fig:ModelSec}.
